来源：数据仓库与分析
数仓工作是一个系统工作，涉及到的内容和技能很多，从分工来说分为ETL、模型、应用、离线、实时、规范、平台、工具、产品、交互、保障、数据体系等等各个方面。从整体结构上来说，很多年都没有变化了，但是具体实现技术却是日新月异。
本文将作为一个新的系列文章，记录日常碰见的问题，以及自己的思考。
上图是常见数据系统的整体框架，当然不同的公司或多或少缺少些组件，这些不影响仓库的好坏。
一个好的仓库，要有优秀的规范，要有好的模型，更重要的是日常管理。
在券商或者基金应该主要是靠供应商来实现，这种结果导致的弊端是仓库极度不自主，而且供应商的人员参差不齐，难以管理。更主要的是很多甲方人员退化为眼高手低的角色。
这块工作很重要，占比也是很大，出现的问题也是最多的，常见的问题如下：
数据晚到，但是不报错
数据不到
数据有乱码，换行等文件
一天需要多个批次
频繁需要手工补数
表结构经常变更
调度管理
源系统，目标系统对应关系
下面对各个问题进行分析。
01
01
源系统问题
问题1、2、3是频发问题，因为对应仓库来说，源系统太多了，总有这种那种问题的，这里也没有好的解决方案，总的来说就是监控加管理吧！
监控是有必要的，毕竟仓库批量的时间窗口有限，有问题要及时处理，从这个角度来说数据仓库的从业人员还是比较辛苦的！
针对数据晚到，还有一种方法，就是拆分，ETL作业拆分的越细，可以让先到的先跑，后到的后跑，这样晚到的作业影响的越小，只是这样必须对仓库的整个依赖要有一个清晰的了解，漏依赖或者多依赖对仓库跑批都有很大的影响。
数据不到这种情况，也是有的，只有催数据了，就需要做一个模板，各个系统常到的时间节点，比如节点加上最早达到时间，最迟到达时间，到达时间中位数信息等等。超过最迟时间要报警通知处理了。
数据乱码，换行等特殊字符问题，一方面使用国际通用编码UTF8，其他编码比如GBK和GB2312也是常用的编码，但是对汉字或者字符的覆盖不是那么全面。
这里还是一个管理问题，比如规定源系统的问题归源系统解决，那么换行，乱码很多问题都是源系统解决，源系统作为数据来源，在数据入库的过程中进行过滤处理。
02
01
调度问题
ETL的需求多种多样，有的需要一天跑一次，有的需要根据标志来采集推送，有的需要，有的需要一天采集多次，有的需要按需采集推送；
作为ETL工作，一般承当离线的数据，要求按需采集其实需求是不合理。
所以目前出现的问题理论上都是管理问题，应该在实时方式实现。
当然，这些问题要实现也是可以的，需要提供自定义的接口实现。
03
01
管理问题
目前，工作量最大的是表结构变化产生的影响，这一块最好的方法就是管控起来；使用一个小组实现集团级的表结构管控和审批，每次变更进行申请，审核通过后及时的通知下游。
频繁的补数其实是更大的管理问题，理论上数据推送到目标后，目标系统第一步就是备份，数据的补录理论上是出现大的生产事故。
比较好的方案是每周做一个数据质量报告，汇报补数的情况。
根据文章前面的总图，ETL工作其实就是采集源系统的信息，推送到数据仓库的原始数据层；数据的采集只是开始，数据仓库的很多重点工作都在模型。
01
01
模型基本设计
在模型设计上，有很多方法，比如ER建模，维度建模，阿里的onedata建模方法等等；
在建模方法上有些区别，业务快速发展的公司或者行业适合维度建模，稳定的金融公司ER建模比较多点。常见的模型设计更多的根据实际情况融合两种建模方法。
阿里的onedate采取类似从上到下的方式，先划分数据域，再拆分数据域中的业务过程，明确可分析维度，最后根据业务过程和可分析维度构建总线矩阵，如下所示。
02
01
维度与指标
指标，是衡量事务发展程度的单位和方法，通常需要经过加和、平均等聚合统计才能得到，并且是在一定条件下的。比如在互联网中常用的UV/PV，页面停留时长，用户获取成本，就是指标；
维度，是事务现象的某种特征，如性别，地区，时间都是维度。比如地域，版本，操作系统等都是维度；
模型设计中拆分好维度后接着分析指标。
03
01
数据指标设计
参考数据仓库之仓库指标体系，对指标有一个基本的介绍，在设计指标的过程中，不仅要熟悉一点业务过程，还要对整个仓库有很熟悉的了解。
指标，最好是得到业务认可的指标是事半功倍的，根据第二点，不同的维度下面都有指标，有的指标名称都是一样的，只是所属维度不同，那么构建⼀致性维度或者一致性指标就很重要了。指标的作用如下：
衡量业务发展质量
建立指标因果关系
指导用户分析工作
指导基础数据建设
指导内容产品建设
统一指标消费口径
相关的方法论或者实践可以参考滴滴的
滴滴数据仓库指标体系建设实践
04
01
模型数据标准
模型的数据标准，可以参考之前写的文章数据仓库之仓库基础数据标准，这里额外强调3点：
模型的数据标准里面，需要规定常见字段中英文对照关系。同样是账户，建表的时候使用的英文千差万别，提供这样一个对照表，尽可能的规范化。
数据仓库的表名需要有一定的命名规则，比如ODS_业务系统数据库名_业务系统数据库表名.
编码标准与规则至关重要，码表多且繁杂，但是非常有用；如果不能好好管理，后期使用起来又很不方便。
05
01
模型的管理工具
模型是需要好好管理的，内容太多太杂。管理过程也是自上向下的，包括域管理，维度管理、度量和字段基础字典的管理，同时具备模型设计审批流程的控制。
上文中ETL问题谈到文件的加载，模型问题谈模型设计和管理，模型往上，就是轻度汇总层
好的仓库还是靠模型，模型的工作量也是最大的，根据主题域或者业务域对域内的信息进行归纳整理，其实也是部分指标开发的原始工作。
01
01
轻度汇总的目的
轻度汇总在很多小的公司，可以没有必要存在，因为相关的工作在模型层已经做了；基本上大部分公司没必要做。
轻度汇总主要是做一些公共的，可以复用的计算，供上层使用，所以主要目的还是复用。
这里要注意的是，不要给模型使用，而是给上层使用；要保证依赖是底层往上的，而不是可以形成闭环的。
02
01
轻度汇总的设计开发
轻度汇总的原表最好来源于模型表，极少部分来源原始数据层，这个必须管控好；
日常开发，所有的业务都可以取原始数据层的，这样可能开发显的更加快。从单个作业的角度，的确可能存在的，从仓库整体的角度是非常不利的，造成的结果是积重难返，直接绕开了模型。对于上层应用来说最好使用模型。
集市层的存在，主要是方便应用，一个应用可能需要很多列数据，而模型或者汇总层一般需要关联操作，这样就显得比较慢。
01
01
集市的目的
从我的角度看，集市的目的就是空间换时间，比如客户集市，就是开发客户的各种各样的大宽表，对外提供数据。
02
01
集市的设计
集市内部也不仅仅是大宽表，如果是这样，列的长度就不能限制了；还有不同的大宽表都有很多重复的列，不可能不加以限制吧。
集市表的设计方面，更多的根据需求来。但是也需要抓住核心，主表附表要设计好。
现在仓库大概的雏形搭建出来了，那么模型或者仓库的设计合理吗？如何判断是否合理呢！
有一个很好的办法就是访问统计。
01
01
完善度
完善度关注什么呢！首先就是跨层引用的情况，一般业务依赖是一层一层的，集市访问模型可以理解，访问原始数据层过多是有很大问题的，当然访问模型比例过大也是有问题的，说明轻度汇总做的不够。
要知道汇总数据查询的够不够，其实就是看需要汇总的业务查询的依赖中是否使用轻度汇总层的表。
02
01
复用情况
下图就是复用较差的模型和仓库设计，我们可以统计模型或者轻度汇总层的表的引用系数来查看复用率。
03
01
名称规则
主要是检查仓库任何一张表，能否看出处于什么层，或者什么域。每层没域都有自己的命名规则，还有历史表，拉链表，切片表都有自己的命名规则。
另外很麻烦的一块就是编码，编码是否转码了，意思是否一致，这个需要开发过程中不停的验证。
04
01
作业拆分
开始的模型设计可能比较粗放，是否有必要进行拆分，这样一个主题下一个业务过程可能有不同的模型表，好处就是仓库可能跑的更快，而不是需要等待数据完全到位后才跑。
随着监管的越来越严格，数据治理越来越受到重视，关于数据治理体系框架也层出不穷，现简单介绍常见的几个框架，供大家参考，在具体实践中，一般是几个框架结合使用。
数据以及数据资产越来越受到重视，如何规范有效的管理企业的数据资产以及越来越受到重视。
关于如何规范有效的管理数据，涉及组织架构、原则、过程和规则，以确保数据管理的各项职能得到正确的履行。根据管理切入的视角和侧重点不同，业界常见的对数据治理的定义已经在几十种，到目前为止DAMA（国际数据管理协会）、ISACA（国际信息系统审计和控制协会）、DGI（国际数据治理研究所）、IBM数据治理委员会和Gartner公司等权威机构提出的定义最具代表性，并被不同类型的企业接受和认可。
01
01
国际标准化组织ISO38500治理框架
国际标准组织于2008年推出第一个IT治理的国际标准：ISO38500, 它的出标志着IT 治理从概念模糊的探讨阶段进入了正确认识的发展阶段，而且也标志着信息化正式进入IT 治理时代。
ISO38500提出了IT治理框架（包括目标、原则和模型），并认为该框架同样适用于数据治理领域。
在目标方面，ISO38500认为IT治理的目标就是促进组织高效、合理地利用IT。
在原则方面，ISO38500定义了IT治理的六个基本原则：职责、策略、采购、绩效、符合和人员行为，这些原则阐述了指导决策的推荐行为，每个原则描述了应该采取的措施，但并未说明如何、何时及由谁来实施这些原则。
中国人喜欢标准，虽然这个关于数据治理没有详细说明。
02
01
DAMA数据治理框架
DAMA认为数据治理是对数据资产管理行使权力和控制，包括规划、监控和执行。它还对数据治理和IT治理进行了区分：IT治理的对象是IT投资、IT应用组合和IT项目组合，而数据治理的对象是数据。
DAMA的数据治理框架分两个，一个是功能要素，一个是环境。
功能要素主要包括技术，环境主要是组织，角色，文化等等。
03
01
DGI
国际数据治理研究所DGI的数据治理框架认为数据治理不同于IT治理，应建立独立的数据治理理论体系。DGI从组织、规则、流程三个层面，总结了数据治理的十大关键要素，创新地提出了DGI数据治理框架。DGI框架以一种非常直观的方式，展示了十个基本组件间的逻辑关系，形成了一个从方法到实施的自成一体的完整系统。组件按职能划分为三组：规则与协同工作规范、人员与组织结构、流程。
DGI强调组织，人，流程，规则，其中人和组织上设立数据治理委员会。
04
01
IBM 数据治理框架
IBM数据治理委员会结合数据的特性，针对性地提出了数据治理的成熟度模型。
在构建数据治理统一框架方面，提出了数据治理的要素模型，并认为业务目标或成果是数据治理的最关键命题。
在要素模型中，有三个促成因素会影响业务目标实现，即组织结构和认知度、政策和数据相关责任者；在促成因素之外，必须重点关注数据治理的核心要素和支撑要素，具体包括数据质量管理、信息生命周期管理、信息安全和隐私、数据架构、分类和元数据，以及审计、日志和报告
05
01
Gartner数据治理体系框架
Gartner数据治理体系框架认为，数据治理来源于IT治理的体系，IT治理来源公司治理的体系。
有的公司是事业部制度，有的是集团制度，导致的结果就是集团的集中治理，事业部的分散治理。
Gartne还认为标准是数据治理的组成部分，有数据定义标准，技术开发标准等等
06
01
DCMM数据治理体系框架
DCMM（Data Management Capability Maturity Assessment Model，数据管理能力成熟度评估模型）是我国首个数据管理领域国家标准，国内很流行。
DCMM将组织内部数据能力划分为八个重要组成部分，描述了每个组成部分的定义、功能、目标和标准。该标准适用于信息系统的建设单位，应用单位等进行数据管理时候的规划，设计和评估。也可以作为针对信息系统建设状况的指导、监督和检查的依据。
DCMM国家标准结合数据生命周期管理各个阶段的特征，按照组织、制度、流程、技术对数据管理能力进行了分析、总结，提炼出组织数据管理的八大过程域，并对每项能力域进行了二级过程项（28个过程项）和发展等级的划分（5个等级）以及相关功能介绍和评定指标（441项指标）的制定。
数据战略：数据战略规划、数据战略实施、数据战略评估；
数据治理：数据治理组织、数据制度建设、数据治理沟通；
数据架构：数据模型、数据分布、数据集成与共享、元数据管理；
数据应用：数据分析、数据开放共享、数据服务；
数据安全：数据安全策略、数据安全管理、数据安全审计；
数据质量：数据质量需求、数据质量检查、数据质量分析、数据质量提升；
数据标准：业务数据、参考数据和主数据、数据元、指标数据；
数据生存周期：数据需求、数据设计和开放、数据运维、数据退役。
总结
今天分享的内容有点多，满满的干货，记得收藏学习或转发朋友圈哦！Day Day UP，努力和汗水总会能得到回报的。关注我们一起进步，我们下期见~~~
资源获取 获取Flink，Spark，程序员必备软件，hive，Hadoop，面试题，数据治理等资源请公众号后台回复关键词：flink，hive，hbase，数据治理，数据质量，机器学习等；也可以公众号菜单栏自行查看更多精彩专题。
下载资料：长按扫码回复 数仓
希望这篇文章可以帮到你~